Tagging subscribers to this area: @dotnet/area-extensions-logging
See info in area-owners.md if you want to be subscribed.

A note on JSON output and custom encoders:

JsonConsoleFormatter delegates character escaping to  Utf8JsonWriter, which by default escapes all control characters. This means dangerous characters like ESC or bidi overrides will appear as  \u001B  etc. in the JSON output without us needing to do anything extra.

However, dotnet's JSON writer supports pluggable encoders, and one of them,  JavaScriptEncoder.UnsafeRelaxedJsonEscaping, deliberately relaxes what gets escaped. If someone explicitly configures their JsonConsoleFormatterOptions.JsonWriterOptions to use this encoder, certain invisible/directional Unicode characters (the kind that can mislead someone reading raw text) will pass through unescaped.

Why we should leave it as it for now:

• The encoder's name literally contains "Unsafe", so using it is a deliberate opt-in to relaxed behaviour.
• JSON logs are typically consumed by log aggregators (Seq, ELK, Datadog, etc.) which parse the JSON and display values in their own UI, not by someone  displaying a file in a terminal.
• Adding pre-sanitisation for this edge case would complicate the default path and risk double-escaping for the majority of users who haven't changed the encoder.

If this proves to be a real-world concern, we can add targeted sanitisation to the JSON path later without any API change.

Are we sure that Console Logger is right place to do such sanitization? I think it will negatively impact performance, even in many case when static constant strings are passed and sanitization will happen every time they are logged which seems like big overhead considering MECFG scale. I did not read thread model or any related documents, but to me it seems that this should be responsibility of caller.

Are we sure that Console Logger is right place to do such sanitization? I think it will negatively impact performance, even in many case when static constant strings are passed and sanitization will happen every time they are logged which seems like big overhead considering MECFG scale. I did not read thread model or any related documents, but to me it seems that this should be responsibility of caller.

@BrennanConroy, @halter73, do you have any thoughts? Honestly, the argument users are supposed to sanitise the log message because they know the context, makes complete sense. We can still provide a convenience method to help them.

The logger implementation (Console) knows what safe and unsafe input for its output is, the logging callers (app code) does not know what is safe or unsafe.

Following up on the performance question raised above. Independent of where sanitization ultimately lives, if it stays in the Console logger it runs on the hot path for every message, exception, category, and scope on every log call. The current detection scan (GetFirstEscapedCharacterIndex calling the per-character ShouldEscape switch) is scalar, so even the common case (plain text with nothing to escape) pays a full O(n) branchy walk of every string.

The same escape set can be expressed as a static SearchValues<char> and scanned with a vectorized IndexOfAny. Measuring the detection scan only (both are zero-alloc on the common path), net8.0 x64:

(Local numbers, not CI hardware, so treat the absolute values as indicative.) The cost is pure CPU per log call, multiplied across the four sanitized values.

Suggestions:

• Use a static SearchValues<char> for the detection scan (value.AsSpan().IndexOfAny(...)), available on net8.0+, keeping the existing #if NET pattern for a scalar fallback on netstandard2.0/net462.
• In the escape-building path, use IndexOfAny to find the next character to escape and bulk-copy the safe run, rather than appending one character at a time.
• category is constant per logger instance but is re-scanned on every call; it could be sanitized once.

This keeps the point that the logger is the right place to know what is unsafe for its output, while removing the per-call overhead.

So here is what we pay for the sanitisation in terms of performance:

Of course, the most important scenario is Clean, where there are no undesirable characters. Moreover, this only affects the Simple and Systemd formatters (JSON has its own escaping) for console logging, where we can reasonably expect two things:

1. High-throughput systems are unlikely to log a lot to the console (which is itself hardly performant).
2. Our formatter is intentionally designed as a safe default, and users are expected to provide their own formatter if they need custom behaviour.

One option we could consider is providing a version of the formatter without sanitisation as a non-default alternative, perhaps called something like UnsafeFormatter, to prevent users from repeatedly copying our old code. That said, I'd wait before doing that. We can reasonably expect that most users rely on console logging primarily for testing, debugging, and local development, where the performance difference is unlikely to be a deal-breaker.

One adjustment we can do is dropping bidi overrides, zero-width, BOM, soft-hyphen and the other scattered Cf chars are not terminal-control vectors. The reason isn't performance but industry practice as both OpenSSH and systemd basically filter C0+DEL+C1 sets (systemd escapes \r since it's unix focused).

We can reasonably expect that most users rely on console logging primarily for testing, debugging, and local development

I don't agree with that statement...

where the performance difference is unlikely to be a deal-breaker.

...but I do agree with that - apps where console logging is used as primary mechanism the performance difference is not going to be a problem.

@tarekgh, thank you for the idea, implemented, the perf results I posted above already use it.